Small tools, long half-life

I keep a folder of things I have written for myself. Most of them are under two hundred lines. The oldest is from 2016 and I have not touched it since 2019, when I fixed a date format. It still runs every morning.

Meanwhile, nearly every ambitious thing I have built for myself is dead. Not deleted — dead. It sits there requiring a runtime I no longer have installed, pointed at an API that changed its auth scheme, waiting for a migration I will never run.

The half-life of a dependency

Nothing about the small tools is better engineered. They survive because they ask for almost nothing, and everything they ask for has been stable for twenty years: a file, a pipe, a text format, a clock.

The ambitious ones asked for a package ecosystem, a build step, a hosted database, and someone else's uptime. Each of those has a half-life. Stack four of them and the tool's lifespan is the shortest one, minus your patience.

A personal tool's expected lifetime is roughly the lifetime of its least stable dependency, divided by how much you still care.

That last term is the one people forget. Maintenance is not free even when it is easy, because the cost is paid in attention on a morning when you wanted to do something else.

Build for the version of you who forgot

The practical rule I have landed on: a personal tool should be something I could reconstruct in an afternoon from scratch, without notes. Not because I plan to, but because that constraint keeps out exactly the complexity that kills it.

It means the state lives in a file I can open. It means the configuration is at the top of the file, not in a separate directory nobody remembers creating. It means there is no database when a folder would do.

• One file if possible, one folder if not
• Plain text for anything I will want to grep in four years
• No step between saving and running
• A comment at the top saying what it is for, because I will not remember

The larger point

I do not think this generalises cleanly to products. Products have users, and users need the things that make software heavy: accounts, migrations, upgrade paths, someone on call.

But it generalises to the part of a product that nobody has budgeted for — the internal script, the deploy helper, the one-off report that quietly became load-bearing. Those live under exactly the same physics as my folder, and they are usually built as if they do not.